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(54) Discovery method for determining information about a signalling network 



(57) A network discovery method is provided for 
determining the functionality existing at the nodes of a 
signalling network. Such a network typically comprises 
a plurality of nodes (BSC, MSC, GSMC, HLR, VLR, EIR) 
each exhibiting one or more types of functionality, and 
point-to-point links inter-connecting the nodes and car- 
rying messages exchanged between nodes, the mes- 
sages having characteristics dependent on the nature 
of the functionality of the nodes between which they are 
exchanged. The discovery method involves using 
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probes (50) and a central station (51) to monitor one or 
more links and to identify from at least one message 
associated with a particular node, a predetermined set 
of message characteristics sufficient to identify a type of 
node functionality possessed by that node. The prede- 
termined set of message characteristics may be derived 
from a single message, from several messages on the 
same or different links, or by observing the message 
transfer characteristics of the node concerned. 
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Description 
TECHNICAL FIELD 

The present invention relates to a network discov- 
ery method for determining information about a signal- 
ling network that comprises a plurality of network nodes 
interconnected by point-to-point links. 

The present invention is applicable, without limita- 
tion, to signalling networks operating substantially in 
accordance with Signalling System No. 7, whether as 
specified by the CCITT, ANSI, ETSI (for GSM), Bellcore 
or similar body. The CCITT Signalling System Number 7 
is specified in Recommendations Q.700-Q.716 CCITT 
Volume VI - Fascicle VI.7, Geneva 1989, ISBN 92-61- 
03511 -6. Except as otherwise required by the context, 
as used herein the term "SS7 network" should be taken 
as referring to any variant of Signalling System No. 7 
including variants in which the physical and link level 
layers are replaced by an alternative link technology 
such as one based on ATM (asynchronous transfer 
mode). 

BACKGROUND ART 

In modern communications technology it has 
become common practice to provide two related but 
separate network infrastructures: a transmission net- 
work for carrying end-user data traffic, and a signalling 
network for controlling operation of the transmission 
network in accordance with control signals transferred 
through the signalling network. In practice such signal- 
ling networks comprise high-speed computers intercon- 
nected by signalling links; computer programs control 
the computers to provide a set of operational and sig- 
nalling functions in accordance with a standardized pro- 
tocol. One example of such a signalling protocol is the 
afore-mentionned Signalling System No. 7 (SS7) which 
is being extensively deployed for control of telephone 
and other data transmission networks. An SS7 network 
basically comprises signalling points (nodes) intercon- 
nected by signalling links, each node having an associ- 
ated functionality (for example, service control point 
functionality, signalling transfer functionality, etc). 

In order to be able to carry out independent moni- 
toring of the signalling network, monitor probes may be 
temporarily or permanently installed on one or more 
links to monitor messages flowing on the link or links. By 
monitoring these messages it is possible to gain an 
insight into the behaviour of the network and to detect 
faults. One example of a monitor probe is the Hewlett- 
Packard 37900B Signalling Test Set. 

When a monitor probe is permanently or semi-per- 
manently installed on a link, generally provision is made 
to have the probe send the results of its monitoring 
operations automatically to a remote management sta- 
tion; this station may also be able to control the probe to 
change the focus of its monitoring activities. Of course, 
for the results coming from a probe to be useful to the 



management station, the location of the probe, in terms 
of the absolute identity of the link on which it is installed, 
must be made known to the management station. Our 
co-pending European patent application No. 

5 describes a discovery method 

by which a monitor probe can automatically determine 
the absolute identity of the link on which it is installed. 

Generally, of course, the information derived from a 
monitor probe, including its network location, is only 
10 useful to a central operator if the configuration of the 
signalling network is already known. However, the con- 
tinuing growth and evolution of the telecommunications 
infrastructure, not least in the area of mobile networks, 
has made the maintenance of an up-to-date record of 
75 the associated signalling network a substantial task par- 
ticularly if it is desired to have immediate access at all 
times to the latest structure of the signalling network. 

It is an object of the invention to provide assistance 
in establishing information about the current composi- 
te tion of a signalling network. 

SUMMARY OF THE INVENTION 

According to one aspect of the present invention, 
25 there is provided a network discovery method for deter- 
mining information about a signalling network that com- 
prises a plurality of network nodes interconnected by 
point-to-point links, the nodes having respective net- 
work addresses on the signalling network and each 
30 having at least one of a plurality of different types of 
node functionality, and the links serving to carry mes- 
sages that are associated with different ones of said 
types of node functionality and have characteristics 
dependent thereon, said messages also including 
35 addressing information associating the messages with 
specific nodes; said method involving: 

(a) - monitoring at least one said link to identify from 
at least one message associated with a particular 

40 said node, a predetermined set of message charac- 
teristics sufficient to identify a said type of node 
functionality possessed by said particular node, 

(b) - providing an output associating the type of 
functionality identified by said set of characteristics 

45 with said particular node. 

The aforesaid predetermined set of message char- 
acteristics may be derived from a single message, this 
message being one for which the said particular node 

so constitutes either the final destination node or the origi- 
nating source node of the message according to the 
addressing information of the message. Where the sig- 
nalling network is an SS7 signalling network, the prede- 
termined set of message characteristics may comprise 

55 a predetermined subsystem number in the SCCP layer 
of the message or a predetermined type of message 
component of the message. In particular, where the sig- 
nalling network forms the signalling network of a GSM- 
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type system, the predetermined message component 
may be a BSSMAP or MAP message component. 

The aforesaid predetermined set of message char- 
acteristics may, alternatively, be built up from character- 
istics derived from a plurality of different messages. 
Thus, where the network is an SS7 signalling network, 
the set of message characteristics may comprise the 
types of user and application parts obsrved for a plural- 
ity of different messages associated with the node con- 
cerned. 

In one embodiment of the invention, the aforeasaid 
set of message characteristics is indicative of a transfer 
characteristic of a node, this transfer characteristic 
being indicative of the node functionality and being 
derived by observing messages both going to and com- 
ing from the node concerned. 

Whilst it would be possible to pick up information 
about a node anywhere on the network where a mes- 
sage orignating from or going to that node may appear, 
it is preferred to determine the functionality of a particu- 
lar node by monitoring messages on at least one said 
link directly connected to that node (indeed, in practice, 
this is often the only place where it is possible to 
observe messages relevant to the node concerned.) In 
the case of a SS7 signalling network, a message may 
be identified as having the required association with a 
node by checking that: 

~ the message has as its originating/destination 
point code the point code of a node at one end of 
the link on which the message is monitored, and 
- where the message has an SCCP component, 
the Global Title translation indicator of the message 
is not set. 

BRIEF DESCRIPTION OF THE DRAWINGS 

A node-discovery method embodying the invention 
will now be described, by way of non-limiting example, 
with reference to the accompanying drawings, in which: 

Figure 1 is a block diagram showing the main com- 
ponents of a GSM cellular mobile radio 
system; 

Figure 2 is a diagram illustrating the basic layered 
architecture of the SS7 system; 

Figure 3 is a diagram illustrating the composition of 
an SS7 message; 

Figure 4 is a flow chart illustrating the processing of 
information from a monitored SS7 mes- 
sage in order to extract node-functionality 
information therefrom in relation to the 
node indicated by the destination point 
code in the routing label of the message; 
and 

Figure 5 is a diagram illustrating the overall collec- 
tion and processing of node functionality 
information from a number of monitor 
probes. 



BEST MODE FOR CARRYING OUT THE INVENTION 

A node-functionality discovery method embodying 
the invention is decribed below in relation to an SS7 sig- 
5 nailing network used to control a mobile radio system. In 
order to facilitate an understanding of the node-func- 
tionality discovery method, a description will first be 
given of the main features of the mobile radio system 
and of the SS7 signalling architecture. 

10 

Example Signalling-Network Environment 

Figure 1 is a diagram showing the main elements of 
a public land mobile network (PLMN) based on digital 

15 cellular radio technology; in particular, the Figure 1 net- 
work is a GSM network. 

The Figure 1 network comprises a network and 
switching subsystem (NSS) 10 which connects with a 
plurality of base station subsystems (BSS) 1 1 ; the BSS 

20 provide radio communication with mobile stations 12 
(only one of which is shown in Figure 1). The NSS 10 
also communicates with the fixed public network 13 (the 
public switched telephone network PSTN and inte- 
grated digital services network ISDN). Indeed the 

25 PLMN can be thought of as an access path to the 
PSTN/ISDN, though calls may also be wholly contained 
within the PLMN. 

Each BSS 1 1 comprises a base station controller 
(BSC) 17, and a plurality of base transceiver stations 

30 (BTS) 18 each controlled by the BSC 1 7. Each BTS 18 
has radio transmitters and receivers for providing radio 
coverage of a local area known as a 'cell'. 

Signalling and user data (digitised voice and other 
digital data such as computer data) pass between each 

35 mobile station 1 2 and the BTS 1 8 of the cell in which the 
mobile station is located. As a mobile station moves 
from one cell to another, control of handover of commu- 
nication with the mobile station from the BTS of the old 
cell to the BTS of the new cell, is effected by the BSC. 

40 The radio interface between a mobile station and 
BTS is standardised within a particular system such as 
GSM. Similarly, the interface between each BTS 18 and 
its associated BSC 1 7, by which user data and signal- 
ling are exchanged between these elements, is also 

45 generally standardised (in GSM, this interface is known 
as the *Abis* interface). 

Each BSS 1 1 communicates with a mobile switch- 
ing centre (MSC) 20 of the NSS 10, each MSC 20 gen- 
erally being in communication with several BSS. The 

so interface between a BSS and an MSC is again generally 
standardised, this interface being known as the A' inter- 
face in GSM, 

In GSM networks, user data and signalling are mul- 
tiplexed across the radio interface, the 'Abis' interface 

55 and the 'A' Interface. However, within the NSS. user 
data and signalling are handled separately. This is 
shown in Figure 1 by depicting user-data paths in solid 
lines and signalling paths in dotted lines; when both use 
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the same path, a solid line with superimposed white 
dots is used. 

In the NSS, the user data is handled by the MSCs 
and for a given call, the user data will commonly 
traverse two MSCs 20. Although in Figure 1 the MSCs 
20 are shown as directly connected by a solid line, this 
should be understood merely as showing that user-data 
traffic can pass between the MSCs; in practice, whilst a 
direct connection is used where justified by traffic levels, 
MSCs may be connected through the intermediary of 
the fixed public network 13. 

In addition to the MSCs 20, user data may also be 
handled in the NSS by what in GSM parlance is known 
as a gateway MSC (GMSC) 21. The purpose of the 
GMSC 21 is to handle calls directed to mobile stations 
from outside of the PLMN, the GMSC determining 
where the call should be routed to catch up with the 
mobile station. In practice, GMSC functionality is often 
provided at each MSC. 

The remaining components of the NSS 10 are con- 
cerned with control functions, these components being: 

the Home Location Register (HLR) 23 - this con- 
tains information about subscribers registered with 
the PLMN (such as the services available to a par- 
ticular subscriber and the PLMN network address 
of the MSC where the subscriber is currently 
located); 

the Visitor Location Register (VLR) 24 - generally, 
each MSC has its own associated VLR which holds 
both subscriber data about users currently visiting 
the area covered by the MSC, and data about the 
current location of each user within the MSCs cov- 
erage area; 

the Authentication Centre (AuC) 25 - this compo- 
nent is closely associated with the HLR and holds 
data providing for subscriber identification and 
encryption of calls; 

the Equipment Identify Register (EIR) 26 - this 
stores information about the mobile stations 12 
themselves; 

the SMS Gateway 27 - in GSM, a special "Short 
Message Service" is available, this being provided 
through the SMS Gateway. 

Signalling within the NSS 10, over the 'A* Interfaces 
to the BSSs 1 1 , and with the fixed public network, is 
effected through signalling links using signalling 
schemes based on the SS7 standard. In particular, 
within the NSS 10 the MAP (Mobile Application Part) 
protocols are used for non-circuit-related signalling traf- 
fic and the TUP (Telephone User Part) and ISUP (ISDN 
User Part) for circuit-related signalling traffic. 

The SS7 signalling network is structured as a 
number of point-to-point links interconnecting nodes at 
which the various PLMN functional components (MSC, 
HLR, BSC, etc.) reside. Each such node, or signalling 
point, has a unique address known as its signalling 
point code. More than one PLMN functional component 
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may reside at a particular node (for example, each MSC 
frequently has an associated co-located VLR) and in 
this case the same point code will be associated with 
several fucntional components; it is then the responsibil- 

5 ity of the SS7 system to ensure that the messages 
received at this point code are delivered to the appropri- 
ate functional component. The important point to note is 
that a node may have several different types of associ- 
ated functionality. 

io It may also be noted that a node may possess latent 
functionality in terms of how an associated functional 
component is designed to respond to particular failure 
conditions. 

Messages traversing the links of the SS7 signalling 
is network may be any of a large number of different types, 
depending on the nature of the call or action to which 
the message relates and the function specified by the 
message. 

20 SS7 Architecture 

A brief review will next be given of the layered struc- 
ture of the SS7 architecture and of the format of the 
messages passed over the links of the signalling net- 
25 work to implement the SS7 architecture for the Figure 1 
network. 

Figure 2 illustrates the SS7 architecture. Levels 1 to 
3 (referenced 31, 33. 33) form the message transfer 
part (MTP) 34. The MTP 34 is responsible for transfer- 
so ring signalling information between signalling points in 
messages. 

MTP Level 1 (reference 31) defines the physical, 
electrical and functional characteristics of the transmis- 
sion path for signalling. MTP Level 2 (reference 32) 

35 defines the functions and procedures for the transfer of 
signalling messages over a link between two directly- 
connected signalling points. The Level 2 functions pro- 
vide a framework in which the information is transferred 
and performs error-detection and error-correction proc- 

40 esses; the Level 2 functions are carried out afresh on a 
link-by-link basis. At Level 2, information is seen as 
being transferred between signalling points in mes- 
sages known as "signal units". 

MTP Level 3 (reference 33) provides functions for 

45 the reliable transfer of signalling information from one 
signalling end point to another. Thus, Level 3 is respon- 
sible for those functions that are appropriate to a 
number of signalling links, these being separable into 
signalling-message handling functions and signalling- 

50 network management functions. Level 3 related infor- 
mation will therefore include addressing information, 
this being in the form of point codes. 

MTP Level 4 (not referenced as a whole) includes 
circuit-related user parts such as ISDN User Part 36 

55 and Telephone User Part 37. These user parts define 
the meaning of the circuit-related messages transferred 
by the MTP 34 and provide functionality to the users of 
SS7 (block 40). 
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As well as the circuit-related user parts 36 and 37, 
Level 4 also includes functional elements defining proto- 
cols for non-circuit-related information, such as opera- 
tions, maintenance and administration information, 
network database information, or subscriber location 
information for a mobile network. An important func- 
tional element in these protocols is the Signalling-Con- 
nection-Control Part (SCCP) 35; the SCCP 35 actually 
forms part of the transfer mechanism for non-circuit- 
related applications, combining with MTP 34 to provide 
a transfer mechanism meeting the OS I Layer 3/4 
boundary requirements. At the level of the SCCP, mes- 
sages may include addressing information additional to 
that contained in the Level 3 point codes; in particular, 
SCCP-level information may include Global Title infor- 
mation for determining a final message destination that 
may be outside of the local network (in this case, the 
Figure 1 PLMN). 

On top of the SCCP 35 sits the Transaction Capa- 
bilities (TC) 38 above which is a TC Users element 39; 
in the present case, the element 39 is formed by the 
Mobile Applications Part (MAP). As is indicated in the 
Figure 1 , MAP is concerned with a number of protocols 
(MAP/B, MAP/C, MAP/D, MAP/E, MAP/F, MAP/G) used 
for communication between the various functional ele- 
ments of the NSS 10. 

Also sitting on top of the SCCP 35 is the Base Sta- 
tion Subsystem Application Part (BSSAP) 41 that 
defines the protocols used for communication between 
a BSS 1 1 and MSC 20 (Figure 1). BSSAP is divided into 
two parts, namely a BSS Management Application sub- 
part (BSSMAP) 42 and a Direct Transfer Application 
sub-part (DTAP) 43. 

To illustrate the SS7 message format, an example 
message will now be considered with reference to Fig- 
ure 3, the particular message chosen being a "handover 
request" message, seen as a BSSMAP message on the 
'A' interface between the BSC and MSC concerned. 

At MTP Level 2, information is transported in signal 
units each comprising: 

Flag Field (8 bits); 

Backward Sequence Number BSN (7 bits); 
Backward- Indicator bit BIB (1 bit); 
Forward Sequence Number FSN (7 bits); 
Forward-Indicator bit (1 bit); 
Length Indicator LI (6 bits); 
Service Information Octet SIO (8 bits); 
Signalling Information Field SIF (8n bits); 
Check Field (16 bits); 
Flag Field (8 bits). 

In fact, there are three types of signal units, namely 
Message Signal Units (MSU) that carry all service and 
application data, Link Status Signal Units (LSSU) that 
are concerned with link status and thus relate to Level 2 
functions, and Fill-in Signal Units (FISU); these different 
types of signal units are identified by the value of the 
Length Indicator LI field of each signal unit. In the 



present example, the LI field indicates that the signal 
unit is an MSU. 

MTP Level 3 information is contained in the SIO 
and in a routing label forming part of the Level 2 signal- 

5 ling information field. The SIO provides an indication of 
the nature - User Part or SCCP - of the higher-level 
information carried in the message; in the present 
example, SCCP is indicated. The routing label includes 
originating (source) and destination addresses for the 

10 signal unit in terms of point codes; these source and 
destination point codes relate to the current message 
hop (which may involve routing via intermediate signal- 
ling points). Note, however, that these point codes may 
not indicate the overall message source and destination 

15 in cases where the SCCP Global Title is used for routing 
(for example, to send the message outside of the local 
SS7 domain) thereby causing one (or more) intermedi- 
ate signalling points to examine the Global Title and 
generate a new routing label (with new source and des- 

20 tination addresses) for the next message hop towards 
the final destination appropriate for the Global Title con- 
cerned. In the present example of a "handover request" 
message, the source and destination point codes in the 
routing label do, in fact, indicate the true source and 

25 destination of the message, the source being the MSC 
concerned and the destination the BSC involved in the 
handover. 

Above MTP Level 3 is the SCCP layer for carrying 
information according to a required service type (con- 

30 nectionless or connection-orientated); the SCCP 
header information relates to provision of this service as 
well as specifying further addressing information such 
as Global Title and sub-system number SSN, this latter 
being an indication of the nature of the end-user func- 

35 tionality (for example, HLR) to which the message is 
directed. In the present example, the SSN will be 'FE' in 
hex, indicating that the message is a BSSAP message 
exchanged between a BSC and an MSC. However, it 
should be noted that where a connection-oriented serv- 

40 ice is established between the source and destination 
nodes (as with BSSAP message exchanges), the SSN 
of an individual message in the middle of a dialogue will 
not be directly available since the normal SCCP 
addressing information is replaced after connection set 

45 up by source and destination reference numbers. Nev- 
ertheless, by monitoring the connection request mes- 
sages (which contain the full SCCP addressing fields), a 
mapping can be established between the reference 
number present in a message and the corresponding 

so full addressing information, including the Global Title 
and SSN associated with the message. In the following, 
it will be assumed that this mechanism is employed in 
relation to the monitoring of connection-oriented mes- 
sages so that SCCP addressing information such as 

55 Global Title and SSN is available in respect of each 
monitored message. 

For a BSSAP message, the Global Title information 
of the SCCP header is irrelevant as BSSAP messages 
always pass directly between a BSC and MSC. How- 
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ever, it is convenient to note here that where the Global 
Title information is needed for routing a message, then 
an associated Global Title Indicator bit (or routing indi- 
cator bit) is set in the SCCP header by the originating 
signalling point; the signalling point receiving the mes- 
sage after its first hop knows from the Global Title Indi- 
cator (GTI) bit that it must effect a Global Title 
translation to identifying the next hop destination of the 
message. If this next hop destination is to be the final 
message destination, the GTI bit is reset before the 
message is sent on. 

In the BSSAP layer above the SCCP, a discrimina- 
tor octet (DSCR in Figure 3) indicates whether the BSS- 
MAP or DTAP sub-parts are involved. In the present 
example, it is the BSSMAP sub-part that is involved. 

Finally, at the BSSMAP level, the message type is 
indicated by the value of a message type field, this value 
being '10' for the current example of a "handover 
request" message. 

Overview of Node- Functionality Discovery Method 

According to the present invention, the functionality 
existing at one or more nodes of the signalling network 
is determined by observing the SS7 signalling traffic 
associated with such node or nodes. More particularly, 
it is necessary both: 

(a) to establish an association between one or more 
monitored messages and a particular node; and 

(b) to deduce the functionality of the node of inter- 
est from characteristics of the associated monitored 
messages. 

With regard to the first task (a), for the most part the 
characteristics of a message are indicative of function- 
ality existing at the source node first giving rise to the 
message and/or at the intended final destination node 
of the message. For circuit-related traffic, these nodes 
correspond to those identified by the point codes in the 
message routing label. However, for non-circuit-related 
traffic, the point codes in the routing label of a monitored 
message may not correspond to the true source and 
destination nodes due to the fact that the message may 
be subject to global title translation either before or after 
being monitored. One simple way of overcoming this 
problem is only to associate a non-circuit-related mes- 
sage with a particular node if: 

- the message concerned is observed on a link 
directly connected to the particular node of interest, 
and 

- the originating/destination point code in the mes- 
sage routing label corresponds to the point code of 
that node, and 

- the Global Title Indicator bit for the address con- 
cerned is not set in the SCCP header. 



Certain node functionality may not, however, be 
associate . with the true source and destination nodes 
of a message but with an intermediate node along the 
route taken by the message; an example of such func- 

5 tionality is signalling transfer point functionality pro- 
vided, for example, in US fixed wire AIN networks and 
serving as signalling gateways between operators. In 
such cases, node functionality will require looking at 
selected characteristics of messages passing through 

w the node - however, there is no difficulty in identifying 
such messages as the point codes in the message rout- 
ing labels are sufficient for this task. 

With regard to task (b) - the determination of node 
functionality from a set of one or more message charac- 

75 teristics - three different approaches can be identified, 
though for any given type of node functionality not all 
approaches may be applicable; these three approaches 
are as follows: 

20 (i) A set of one or more message characteristics is 
identified that unambiguously indicates the exist- 
ence of a particular type of node functionality, the 
selected characteristics being known all to occur in 
the same message. This set of characteristics is 
25 then searched for in each relevant message taken 
independently. An example of this type of approach 
is the identification of MSC functionality by detect- 
ing a "handover request" message on an "A" inter- 
face; another example is the use of subsystem 
30 number to identify HLR functionality. 

(ii) A set of two or more message characteristics is 
identified that unambiguously indicates the exist- 
ence of a particular type of node functionality; how- 
ever, the selected characteristics do not all occur in 

35 the same message. This set of characteristics is 
then searched for in the relevant messages and the 
occurrence of all such characteristics in relation to a 
particular node is taken to indicate that the node 
possesses the corresponding type of functionality. 
40 An example of this type of approach is the identifi- 
cation of MSC functionality by detecting BSSMAP 
application parts and TUP/ISDN user parts associ- 
ated with the same node. 

(iii) The transfer characteristics of a node may be 
45 examined to see if there is a consistent difference 

between inbound and outbound messages betray- 
ing some functionality possessed by the node. For 
example, if the number of inbound messages with 
the GTI bit set significantly exceeds the number of 

so outbound messages with the GTI bit set, then this 
indicates that the node concerned is effecting glo- 
bal title translation (and may therefore possesses 
STP functionality - this would almost certainly be 
the case if the node was not a source or sink of 

55 voice-related traffic). 

Whilst approach (i), and in certain cases approach 
(ii), can be done using observations on a single link, 
generally approach (ii) and always approach (iii) 
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requires the collation and analysis of observations 
made on several links. In fact, it is also useful for 
approach (i) to compare results obtained from observa- 
tions made on different links to check for consistency. 

5 

Implementation of Node-Functionality Discovery 
Method 

In the present embodiment, monitor probes 50 (see 
Figure 1) are connected into selected ones of the sig- 10 
nailing links and these probes are arranged to feed back 
the results of their observations to a central station 51 
over a communications network 52. For clarity, in Figure 
1 the monitor probes are shown as black triangles with 
only some of the probes being referenced and only one 15 
having its connection to the station 51 shown. An SS7 
link is arranged as two oppositely directed channels and 
each probe 50 is arranged to monitor both channels of 
the link in which it is inserted. 

The processing of each message monitored by a 20 
probe 50 will now be described with reference to Figure 
4. It is assumed that the probe knows the point codes of 
the nodes at the ends of the link it is monitoring; such 
information may be externally provided at the time of 
probe installation or may be determined by the probe 25 
itself according to the method described in our above- 
mentioned patent application. 

For each link-end node as represented by its point 
code, the probe maintains a record 56 for holding func- 
tionality-related information determined for the node 30 
concerned. This record 56 has three functionality- 
related fields 57, 58, 59 each for holding information 
determined according to a respective one of the three 
approaches discussed above. Thus the "function" field 
57 holds the identity of particular functionality uniquely 35 
identified from the examination of one message; this 
field is a bitmap 57 with the setting of each bit represent- 
ing the possession of a corresponding predetermined 
functionality by the node concerned. The "parts" 58 field 
serves to collect information on the user and application 40 
parts of messages sent to the node concerned, this 
information being intended to be considered cumula- 
tively with information from other probes to enable node 
functionality to be determined according to the second 
approach discussed above; the "parts" field 58 is also a 45 
bitmap with each bit being indicative of the presence or 
absence of a particular user/application part associated 
with the node concerned. Finally, the "xfer" field 59 is 
used to contain transfer characteristic information on 
the node concerned; in the present case this informa- so 
tion takes the form of counts of inbound and outbound 
messages having the GTI bit set, these counts being 
held in respective sub-fields. 

Upon a message being monitored by the probe 50, 
the processing represented in Figure 4 is initiated (block 55 
60). The destination point code DPC in the message 
routing label is first checked to see if it corresponds to 
one of the link-end point codes; if it does not, Figure 4 
processing is terminated (block 61). If the DPC does 



correspond to a link-end point code, the SIO is looked at 
to see if the message carries a user part TUP or ISUP, 
or non-circuit related information i.e. is SCCP based 
(see block 62). Where a user part is identified, the 
nature of this user part is recorded in the "parts" field 58 
of the record held for the node identified by the DPC 
(block 70) after which the Figure 4 processing is termi- 
nated (block 71); where an SCCP-based message is 
identified, processing passes to block 63. 

In block 63, a check is made on the Global Title 
Indicator bit for the destination address in the SCCP 
header. If the GTI bit is set, the message is only used for 
collecting transfer characteristic information - in particu- 
lar, the count held in the inbound subfield of field 59 of 
the record corresponding to the message DPC is incre- 
mented (block 64) after which Figure 4 processing is 
terminated (block 71). On the other hand, if the GTI bit 
is not set, the message is further examined to extract 
functionality-related information according to the first 
and/or second approaches referred to above. To this 
end, the subsystem number SSN of the message is 
next examined (block 65). 

Generally, the SSN will by itself indicate a type of 
functionality existing at the final destination node of the 
message; however, for messages on an "A" link, a sub- 
system number of "FE" (hex) indicates the BSSMAP 
application part and is thus carried both by messages 
going from the BSC concerned to the corresponding 
MSC and messages going from the MSC to the BSC. 
Accordingly, if an SSN other than "FE" is detected, the 
corresponding functionality is recorded in the "function" 
field of the DPC's record (block 69), whereas if an SSN 
of "FE" is detected the "parts" field of the DPC's record 
is updated to note the association of the BSSMAP appli- 
cation part with the node represented by the DPC (block 
66). 

In fact, for BSSMAP messages, specific node func- 
tionality for the DPC can usually be determined by 
detailed examination of message type since many of 
the messages on the "A" interface are uni-directional. 
For example, "handover request" messages only pass 
from a BSC to an MSC so that detection of such a mes- 
sage (block 67) permits the functionality of the DPC 
node to be determined and the "function" field 57 of the 
corresponding record set accordingly (block 68). 

Figure 4 concerns message processing for extract- 
ing functionality information relevant to the node repre- 
sented by the DPC in the routing label. Similar 
processing may thereafter be effected to extract func- 
tionality information for the node represented by the 
originating point code OPC in the message routing 
label. Again, if the GTI bit is set in relation to the source 
address in the SCCP header, then the message is only 
used for collecting transfer characteristic information - in 
particular, the count held in the outbound subfield of 
field 59 of the record corresponding to the message 
OPC is incremented (block 64). It should also be notrd 
that subsystem number relates to the destination node 
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of a message and so is not directly useful in determining 
source node functionality. 

Each probe 50 collects functionality information on 
its link-end nodes over a period of time and peridically 
sends this information to the central station 75 in a 
probe report message 75 (see Figure 5). Each such 
message includes the identity of the probe and the 
records 56 for the two link-end nodes associated with 
the probe. The central station collects and organises the 
probe information (step 76) as illustrated in Figure 6; in 
particular, station 51 maintains a record 77 for each 
point code of which it is aware and then associates with 
this record 77 (through pointer 78) a linked list of the 
probe report sections 80 relevant to the point code con- 
cerned. Thus, if three links associated with a particular 
point code are monitored by probes 50, the three 
records 56 generated in the probes will be organised in 
the central station 51 such that each resides in a 
respective report section 80 and such sections are 
linked through pointers with each other and with the cor- 
responding record 77. 

Either periodically or upon operator request, the 
central station 51 carries out for each point code an 
analysis of the functionality information held in the 
report sections 80 for that point code (step 81, Figure 
6). This analysis will involve: 

-- combining the specific functionalities contained in 
the "function" fields of the report sections 80; 
-- combining the user-part/application-part informa- 
tion contained in the "parts" fields of the report sec- 
tions 80 and then analysing this information to see 
if it contains a set of parts predetermined as being 
characteristic of a particular node functionality; 
- combining the inbound counts, and separately 
the outbound counts, held in the "xfer" fields of the 
report sections 80 and then comparing these 
counts to see if there are significantly more inbound 
counts than outbound counts; if this were the case, 
then the node can be considered as effecting global 
title translation and this could be combinrd with 
other information to deduce a particular node func- 
tionality (thus, although not applicable to the Figure 
1 network, if the node concerned was also found 
not to be a source or sink of voice related traffic, it 
would be reasonable to deduce that the node had 
STP functionality). 

The totality of the functionality types determined for 
the node concerned are then written back into a func- 
tionality bit field 79 of the point code record 77, thereby 
making the information readily available against node 
identity. 

It will appreciated that the foregoing gives only a 
limited set of examples of what is possible. Other exam- 
ples of functionality detection are: 



- in a GSM network, detecting VLR and HLR func- 
tionality by monitoring for the MAP/D "Update Loca- 
tion" that will only pass from a VLR to an HLR; 

- in a GSM network, detecting HLR functionality by 
5 determining the destination node for "Send Routing 

Information" messages; 

- in a GSM network, finding Gateway MSG func- 
tionality by identifying the source of "Send Routing 
Information" messages (such a source should also 

10 be the source and sink of voice related signalling); 

- in a PCS network, finding a Mobile Access Tan- 
dem MAT as being a source and sink of voice 
related traffic whilst not having any BSC attached to 
it (as indicated by the absence of associated BSS- 

is MAP messages). 

It will appreciated that many variants are possible to 
the foregoing node-functionality discovery method. 
Thus, for example, it is not necessary to exclude from 
20 processing at a node these messages that have neither 
a source or a destination point code corresponding to a 
link-end point code. 

Claims 

25 

1 . A network discovery method for determining infor- 
mation about a signalling network that comprises a 
plurality of network nodes interconnected by point- 
to-point links, the nodes having respective network 

30 addresses on the signalling network and each hav- 
ing at least one of a plurality of different types of 
node functionality, and the links serving to carry 
messages that are associated with different ones of 
said types of node functionality and have character- 

35 istics dependent thereon, said messages also 
including addressing information associating the 
messages with specific nodes; said method involv- 
ing: 

40 (a) - monitoring at least one said link to identify 

from at least one message associated with a 
particular said node, a predetermined set of 
message characteristics sufficient to identify a 
said type of node functionality possessed by 

45 said particular node, 

(b) - providing an output associating the type of 
functionality identified by said set of character- 
istics with said particular node. 

so 2. A method according to claim 1 , wherein said prede- 
termined set of message characteristics is derived 
from one said message. 

3. A method according to claim 2, wherein said partic- 
55 ular node constitutes the final destination node of 
said one message according to the said addressing 
information of the message. 
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association with said particular node by checking 
that: 

- the message has as its originating/destina- 
tion point code the point code of a node at one 
end of the link on which the message is moni- 
tored, and 

where the message has an SCCP compo- 
nent, the Global Title translation indicator of the 
message is not set. 

6. A method according to claim 3 or claim 4, wherein 
said network is an SS7 signalling network, said pre- 
determined set of message characteristics com- 
prising a predetermined type of message is 
component of a said message. 

7. A method according to claim 6, wherein said net- 
work forms the signalling network of a GSM-type 
system, said predetermined message component 20 
being a BSSMAP or MAP message component. 

8. A method according to claim 1 , wherein said prede- 
termined set of message characteristics comprises 
characteristics derived from a plurality of different 25 
messages. 

9. A method according to claim 8, wherein said net- 
work is an SS7 signalling network, said set of mes- 
sage characteristics comprising the user and 30 
application parts with which the messages of said 
plurality of messages are associated. 

1 0. A method according to claim 1 , wherein said prede- 
termined set of message characteristics is derived 35 
from messages going to and coming from said par- 
ticular node, said set of message characteristics 
being indicative of a transfer characteristic of that 
node which in turn is indicative of the said type of 
node functionality possessed by said particular 40 
node. 

1 1 . A method according to claim 1 , wherein said prede- 
termined set of message characteristics is derived 
from messages monitored on at least one said link 45 
directly connected to said particular node. 

12. A method according to claim 11, wherein said at 
least one message associated with said particular 
node is one of: so 

- a message having said particular node as its 
final destination node. 

- a message having said particular node as its 
originating source node. 55 

13. A method according to claim 12, wherein said net- 
work is an SS7 signalling network and wherein a 
said message is identified as having the required 
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4. A method according to claim 2, wherein said partic- 
ular node constitutes the originating source node of 
said one message according to the said addressing 
information of the message. 

5 

5. A method according to claim 3 or claim 4, wherein 
said network is an SS7 signalling network, said pre- 
determined set of message characteristics com- 
prising a predetermined subsystem number in the 
SCCP layer of a said message. 10 
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